DEV Community

Stop Flickering UIs: Handle Subdomains with Next.js Edge Middleware ⚡

Prajapati Paresh — Thu, 23 Apr 2026 06:00:10 +0000

The Challenge of Dynamic Subdomains

When scaling a professional B2B SaaS platform at Smart Tech Devs, providing clients with their own custom subdomains (e.g., acme.smarttechdevs.in) is a premium feature that instantly elevates your brand. However, architecting this on the frontend can be complex. In a monolithic React app, you might find yourself writing messy `useEffect` hooks to parse the window.location.host and render different components based on the URL.

This approach is slow, causes screen flickering, and ruins SEO. To build enterprise-grade routing, we must intercept the request before it ever reaches the React rendering engine. We do this using Next.js Edge Middleware.

The Power of the Edge

Next.js Middleware runs on the Edge (e.g., Vercel's Edge Network), meaning the code executes in milliseconds at a server node geographically closest to the user. It intercepts the incoming HTTP request, inspects the headers, and transparently rewrites the URL to the correct internal Next.js route without changing the URL shown in the user's browser.

Step 1: Architecting the App Router Directory

First, we organize our Next.js app/ directory to handle the dynamic rewrites. We create a dynamic route segment specifically for subdomains.


app/
├── (public)/         # Your main marketing site (smarttechdevs.in)
│   └── page.tsx
├── [tenant]/         # The hidden folder where subdomain traffic is routed
│   └── dashboard/
│       └── page.tsx
└── middleware.ts     # The Edge routing engine

Step 2: The Middleware Logic

The middleware.ts file sits at the root of your project. Here, we parse the host header, determine if it is a subdomain, and rewrite the URL transparently to our hidden [tenant] folder.


// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export const config = {
    // Only run middleware on relevant paths (ignore static files, API, etc.)
    matcher: [
        "/((?!api/|_next/|_static/|_vercel|[\\w-]+\\.\\w+).*)",
    ],
};

export default async function middleware(req: NextRequest) {
    const url = req.nextUrl;
    
    // 1. Get hostname (e.g., 'acme.smarttechdevs.in' or 'localhost:3000')
    const hostname = req.headers.get('host') || 'smarttechdevs.in';

    // 2. Define your root domains to exclude them from subdomain logic
    const isRootDomain = hostname === 'smarttechdevs.in' || hostname === 'localhost:3000';

    // 3. Extract the subdomain (if it exists)
    // 'acme.smarttechdevs.in' -> 'acme'
    const subdomain = hostname.replace(`.smarttechdevs.in`, '');

    if (!isRootDomain && subdomain) {
        // 4. Transparent Rewrite: 
        // The user sees 'acme.smarttechdevs.in/dashboard'
        // Next.js internally renders 'app/[tenant]/dashboard/page.tsx' where [tenant] = 'acme'
        return NextResponse.rewrite(new URL(`/${subdomain}${url.pathname}`, req.url));
    }

    // Pass through normal root domain requests untouched
    return NextResponse.next();
}

The Engineering ROI

Using Edge Middleware for subdomain routing fundamentally upgrades your SaaS architecture:

Zero Layout Shift: Because the routing decision happens on the server edge, the user never sees a flash of the wrong layout or a loading spinner while the app figures out who they are.
Blazing Fast Verification: You can also inject JWT authentication verification directly into this middleware, rejecting unauthorized users before they consume any React server rendering resources.
Clean Codebase: Your React components remain pure. They don't have to parse URLs; they simply receive the tenant parameter cleanly as a prop from the dynamic folder structure.

Conclusion

Dynamic subdomains require a dynamic routing strategy. By pushing the heavy lifting of domain parsing to Next.js Edge Middleware, you ensure that your B2B clients receive a perfectly tailored, blazingly fast experience from the very first byte of the page load.

Fonctionnement d’une blockchain - Étape 5/8 : Lien “maillon - maillon”

Amel In Tech — Thu, 23 Apr 2026 05:51:45 +0000

Chaque bloc pointe (par hash) vers le bloc précédent.

Ce chaînage rend l’historique difficile à falsifier car modifier un ancien bloc casserait tous les hashes suivants.

Qu’est-ce qu’un hash ?

Un hash est une empreinte digitale unique créée à partir d’une information.

Une même donnée donne toujours le même hash
Une seule petite modification donne un hash complètement différent
Impossible de retrouver les données à partir du hash (fonction à sens unique)

Chaque bloc contient :

son propre hash
le hash du bloc précédent c'est ce qui crée une chaîne incassable

Comment un hash est créé ?

On prend les données du bloc (transactions, date, racine Merkle, etc.)
On les fait passer dans une fonction de hachage cryptographique (ex : SHA-256 pour Bitcoin).
On obtient une empreinte unique.

Building MCP Servers in Python: a production primer for 2026

Tufail Khan — Thu, 23 Apr 2026 05:49:09 +0000

The Model Context Protocol (MCP) went from "Anthropic side project" to industry standard in eighteen months. As of March 2026, MCP SDKs are pulling 97 million monthly downloads. Every serious agent framework — Claude, Cursor, OpenAI Agents SDK, Microsoft Agent Framework — speaks MCP natively.

If you're a Python backend engineer, MCP is the most leveraged thing you can learn right now. This post is a practical walkthrough of shipping a production-grade MCP server using FastMCP, the Python framework that makes it boring.

What MCP actually is

MCP is a protocol for exposing tools, resources, and prompts to an AI agent in a standardized way. Instead of each agent framework inventing its own adapter format, you write your server once and it plugs into any MCP-compatible client.

Think of it as "USB-C for agents."

A minimal server exposes:

Tools — functions the agent can call (e.g. search_customers, get_order_status)
Resources — URIs the agent can read (e.g. crm://contacts/123)
Prompts — parameterized prompt templates

Starter: a FastMCP server in 40 lines

# server.py
from fastmcp import FastMCP
from pydantic import BaseModel
import httpx

mcp = FastMCP("internal-crm")

class Customer(BaseModel):
    id: str
    name: str
    tier: str
    mrr: float

@mcp.tool()
async def search_customers(query: str, tier: str | None = None) -> list[Customer]:
    """Search the CRM for customers by name or email. Optionally filter by tier."""
    async with httpx.AsyncClient() as client:
        r = await client.get(
            "https://crm.internal/api/search",
            params={"q": query, "tier": tier},
        )
        return [Customer(**row) for row in r.json()]

@mcp.tool()
async def get_customer_notes(customer_id: str) -> str:
    """Fetch the latest account-manager notes for a customer."""
    async with httpx.AsyncClient() as client:
        r = await client.get(f"https://crm.internal/api/notes/{customer_id}")
        return r.text

@mcp.resource("crm://customer/{customer_id}")
async def customer_resource(customer_id: str) -> str:
    """Read-only customer profile."""
    async with httpx.AsyncClient() as client:
        r = await client.get(f"https://crm.internal/api/customer/{customer_id}")
        return r.text

if __name__ == "__main__":
    mcp.run(transport="streamable-http", host="0.0.0.0", port=8000)

That's a complete, production-adjacent MCP server. Type-safe inputs and outputs via Pydantic. Docstrings become tool descriptions the agent reads. Resources get URIs the agent can embed in its context.

The transport shift: stdio → Streamable HTTP

Every MCP tutorial from 2024 used stdio transport — the server runs as a subprocess, the agent pipes JSON-RPC over stdin/stdout. That's fine for desktop tools like Claude Desktop. It's the wrong answer for production.

Streamable HTTP (finalized in the 2025 spec) fixes this:

Servers run as long-lived HTTP services, not per-invocation subprocesses
Scale horizontally behind a load balancer
Share across teams and apps
Deploy once, discover via URL

In FastMCP, the switch is one line: transport="streamable-http".

Auth: OAuth 2.1 the boring way

MCP's 2025 spec added OAuth 2.1 as the standard auth mechanism. You don't roll your own. FastMCP ships with OAuth middleware that plugs into your existing IdP (Auth0, Okta, Cognito, Clerk, etc.):

from fastmcp.auth import OAuth2Middleware

mcp.add_middleware(OAuth2Middleware(
    issuer="https://tufail.auth0.com/",
    audience="mcp-internal-crm",
    required_scope="crm:read",
))

The agent handles the authorization dance. Your server just enforces scopes on each tool.

Deploying to AWS without overspending

Two patterns we've landed on for production MCP:

Pattern A — Low-traffic internal tools: Lambda + API Gateway

Use mangum or FastMCP's ASGI adapter to run inside Lambda
Cold starts ~300-500ms (acceptable for human-speed agent interactions)
Cost: near-zero when idle

Pattern B — High-traffic shared servers: ECS Fargate behind ALB

One service per logical server
Auto-scale on CPU/memory
Pair with ElastiCache for stateful session continuity
Cost: predictable, ~\$30/mo for a small always-on service

The mistake we made early on: treating every MCP server like it needed an always-on Fargate task. For servers that handle <10 agent calls/hour, Lambda is dramatically cheaper.

What to expose — and what not to

The #1 mistake I see is devs exposing their entire internal API as MCP tools. Don't.

Good MCP servers are curated for an agent's use case. Ask: what would a smart human operator need to do their job? Expose those 5-15 tools. Not your 300-endpoint API.

Good tool design:

One clear job per tool. search_customers not crm_unified_query.
Typed inputs and outputs. Pydantic makes this cheap.
Honest docstrings. The agent reads them. Lie in the docstring and the agent will confidently call your tool wrong.
Idempotent where possible. Agents retry. Accept that.

What's next

Remote MCP servers + fine-grained OAuth scopes are unlocking internal-AI-assistant work that was impossible a year ago. If you're a Python backend engineer and you haven't shipped an MCP server yet, pick your highest-leverage internal system and wrap it. You'll be surprised how quickly it changes how your team works.

I Built a Local AI VRAM Calculator & GPU Planner (Beta)

logarithmicspirals — Thu, 23 Apr 2026 05:39:59 +0000

I added a new tool to the site: the Local AI VRAM Calculator & GPU Planner (Beta).

This came out of a problem I kept running into while experimenting with local models. It is surprisingly easy to end up with a setup that technically works, but does not actually match the kind of workloads you want to run.

This is mainly aimed at figuring out GPU and VRAM requirements for running local LLMs. Most advice in this space is broadly correct, but not very specific. Things like “get more VRAM” or “use NVIDIA” help at a high level, but they do not help much when you are comparing a curated set of real GPUs, a manual VRAM tier, different quantization levels, or larger context windows.

I wanted something that made those tradeoffs visible before committing to hardware.

What the Planner Does

The Local AI VRAM Calculator & GPU Planner (Beta) takes a few inputs: a GPU from the site snapshot or a manual VRAM tier, system RAM, quantization level, context length, and the primary workload.

From there it tries to give a practical read on whether the setup makes sense. That includes a rough fit score, GPU-specific notes when you pick a card from the snapshot, and a set of model recommendations based on the selected workload.

The part I focused on the most is the estimate breakdown. Instead of showing a single number, the planner separates the estimate into model weights, KV cache, runtime overhead, total VRAM, and storage.

That makes it easier to see what actually changes when you adjust something like context length or quantization. In a lot of cases, the bottleneck is not where you expect.

The estimates are not meant to be exact. Some are configuration-based, others are heuristic. The tool tries to label that clearly so it is obvious how much confidence to put in each result.

The context selector is also capped by the model metadata currently loaded into the planner. In practice that means the available maximum is based on the current curated model snapshot, plus any public Hugging Face models you import into the tool.

How Much VRAM Do You Need for Local LLMs?

This is the question I kept coming back to, and it is harder to answer than it should be.

As a rough guideline:

Smaller models (7B–8B) can often run on 8–12 GB of VRAM with quantization.
13B–14B models typically need around 12–16 GB.
Larger models usually require 24 GB or more, or some form of offloading.
Context length increases memory usage, sometimes more than expected.
Runtime overhead and KV cache can add a meaningful amount on top of raw model size.

These are not strict rules, but they are useful for avoiding obviously bad configurations.

The planner is meant to make these tradeoffs visible. Instead of guessing whether a model will fit, you can see how each component contributes to total VRAM usage.

Why This Is Single GPU Only

I originally added a multi-GPU option and removed it.

In practice, two GPUs do not behave like one larger pool of VRAM. Some runtimes can split work across devices, but many workflows still depend on the model fitting mostly on a single card. Performance also depends on details that are hard to generalize, like backend support and interconnect behavior.

Given that, a single-GPU estimate felt more honest. If a setup does not make sense on one card, the tool should not imply that adding another card will automatically fix it.

Where This Fits

I wrote previously about using Tailscale to access private LLMs, which focuses on the networking side of running local models.

This tool is more about the step before that: deciding what kind of hardware and model setup is actually reasonable.

In practice, both pieces are part of the same system. Running local LLMs ends up touching hardware, storage, networking, and a few operational decisions that are easy to overlook at the start.

Try It

If you are trying to figure out whether your GPU can run a specific LLM, you can try it here: Local AI VRAM Calculator & GPU Planner (Beta).

It is not a benchmark or a guarantee of how every runtime will behave. It is closer to a planning tool: something that makes the constraints visible and helps avoid obviously bad decisions within the GPU snapshot and model data the site currently ships.

I will keep updating the underlying data as I test more setups.

Shadow Deployments for AI Agents: Test in Prod without breaking anything 🚀

Amar Dhillon — Thu, 23 Apr 2026 05:39:39 +0000

If you’ve worked with AI agents in production, you already know one thing. Deploying a new version is not the same as deploying traditional software

With non AI systems, you push code and then run tests. If everything looks fine then you go live

With agents, things get messy. The same input can produce slightly different outputs. Improvements in reasoning might come with unexpected side effects. Sometimes a “better” model performs worse in edge cases that actually matter

So the real challenge is not building a better agent. The challenge is proving that it’s better before users see it 🔍

Why Traditional Deployment Fails for Agents 🤔

The core issue is that agent behavior is not deterministic. You can’t rely on a handful of test cases and assume production will behave the same way. Even if your offline evaluations look great then real users can bring unpredictable inputs, messy context and ambiguous intent

This means a direct rollout is risky. If something goes wrong, it’s not always obvious. it can give:

Slightly worse answers
Slightly more hallucinations
Slightly longer responses that annoy users

By the time you notice, the damage is already done 😬

The Idea Behind Shadow Deployments 🧠

As shown in the above diagram, instead of replacing your current agent (V1) you run the new version (V2) alongside it

The user sends a request and your system (Orchestrator in this case) does something interesting behind the scenes

The stable agent handles the request as usual and returns the response to the user
At the same time, the new agent (V2) receives the exact same input but its output is never shown to the user. It just runs quietly in the background 🏃🏻‍♂️

This is what I call a shadow path 👻

You are effectively replaying real production traffic through your new agent without exposing any risk. The _user experience _remains unchanged but you now have a way to observe how the new version behaves under real conditions

What Actually Happens Under the Hood? ⚙️

At the center of this setup is an orchestrator; It takes incoming requests and sends them down 2 paths

The first path is the live path, which goes to your stable agent. This is the version you trust. It produces the response that the user sees

The second path is the shadow path. This goes to your canary agent which is the version you’re testing. It receives the same input often with the** same context and knowledge sources** but its output is held back

Its important to note that, to make this comparison meaningful, both agents typically rely on the same knowledge base. If one agent had access to different data, you wouldn’t know whether the difference in output came from better reasoning or just better information. Keeping the data layer consistent ensures you are comparing apples to apples 🍎

Comparing Outputs Is Where the Magic Happens ⚖️

Now comes the tricky part. How do you decide which output is better?

You could try to define strict rules, but language is messy. Quality is subjective. What looks better to one evaluator might not look better to another

This is where the idea of using an LLM-as-a-judge comes in. A reasoning model can evaluate both responses and decide which one is more accurate or more aligned with the user’s intent

Over time, you start collecting signals

Maybe the new agent wins 65% of the time
Maybe it’s more accurate but slightly slower
Maybe it handles complex queries better but struggles with short factual ones

All of this gets logged and analyzed 📊

Turning Observations Into Decisions 🔁

After running this setup for a while, patterns begin to emerge. You can see latency differences, cost implications and even qualitative improvements in reasoning.

At this point, promoting the canary is no longer a risky move;It becomes a controlled decision

If the new agent consistently performs better and meets your criteria, you promote it to production. The canary becomes the new stable version and the cycle continues

Things That Still Need Careful Thought ⚠️

Shadow deployments are powerful but they are not free
Running two agents in parallel increases cost, so many teams sample traffic instead of shadowing everything
Latency also needs to be isolated so the shadow path never slows down the user response
Evaluation quality is another challenge. LLM-as-a-judge works well, but it can be inconsistent. Many teams improve this by combining automated evaluation with occasional human review
Observability becomes critical. You need to track inputs, outputs, context, and decisions in a structured way. Without that, you are just collecting noise

The Bigger Picture 🧩

If you are serious about building production-grade AI agents this is not just a nice-to-have pattern

It’s one of the foundational pieces that makes everything else possible 🚀

Why Technical Startups Fail: Building in a Vacuum

Matthew Gladding — Thu, 23 Apr 2026 05:35:19 +0000

There is a specific, lonely moment that every technical founder eventually faces. It is the moment the code is clean, the architecture is scalable, and the beta version is ready to launch. You look at your screen, proud of the elegant solution you've built, and you expect the world to beat a path to your door. Instead, the silence is deafening.

You send out a few emails to your network. You post a LinkedIn update about the new feature. You wait. And you wait.

This scenario plays out in thousands of garage offices and co-working spaces every single day. The disconnect between a brilliant technical solution and a lack of customers is rarely a failure of the product itself. More often than not, it is a failure of communication. In the world of modern business, technical prowess is no longer enough. If you cannot articulate the value of your work to a human being, your product is effectively invisible.

This is the harsh reality of the content marketing landscape for technical founders. It is a battlefield where the tools of the trade--algorithms, syntax, and architecture--are pitted against the softer skills of persuasion, empathy, and storytelling. Most technical founders fail not because they lack intelligence, but because they approach content marketing with the wrong mindset. They treat it as an afterthought, a chore, or a translation exercise rather than a strategic asset.

Understanding why this happens is the first step toward fixing it. It requires looking past the lines of code and examining the psychological barriers that prevent technical leaders from connecting with their audience. It is a journey from being a builder of things to becoming a builder of a brand, and the transition is where the real work begins.

The Engineer's Dilemma: Why You're Talking to Yourself

The root of the problem often lies deep in the founder's background. Technical founders are trained to solve problems. They are trained to optimize, to debug, and to find the most efficient path from Point A to Point B. This mode of thinking is analytical, linear, and highly precise. However, content marketing is rarely linear; it is contextual, emotional, and conversational.

When a technical founder sits down to write a blog post or a social media update, they often fall into the trap of talking to themselves. They write for their peers, for other engineers, or for the imaginary technical review board. They assume that if the reader understands the complexity of the solution, they will automatically understand the value.

This is a dangerous assumption. The average business user does not care about the specific API endpoint or the algorithmic complexity of your search function. They care about how their life is easier, faster, or more profitable because of what you built. The language of value is not binary; it is human.

Consider the difference between a technical manual and a marketing page. A manual tells you how to do something, assuming you already know why you want to do it. Marketing tells you why you should do it, and then shows you how. Technical founders often struggle to make this switch. They view content as a manual for their product, a way to explain how it works, rather than a pitch for its benefits.

This creates a profound disconnect. You are speaking a language of logic and precision, while your potential customers are looking for a solution to a problem they are feeling emotionally. Until you can translate that complex logic into simple, relatable benefits, you will continue to build in a vacuum. You are the only one who understands the code, and that is a lonely place to be when you are trying to build a business.

The Perfectionism Trap: When Good Enough Becomes the Enemy

If the first hurdle is a lack of audience alignment, the second is often paralysis. Technical founders are often perfectionists by nature. They strive for 100% accuracy. They want their documentation to be flawless. They want their code to be bug-free. They apply this same standard to their content.

However, content marketing is not a research paper. It is a conversation. And conversations, by their very nature, are messy and imperfect. They evolve. They are corrected. They are refined in real-time.

The "Perfectionism Trap" is the belief that you cannot publish anything until it is absolutely perfect. This mindset is the enemy of growth. In the fast-paced world of digital media, speed is often more important than perfection. By waiting for the "perfect" post, you are often waiting until the market has moved on.

Furthermore, technical perfectionism often leads to jargon. There is a comfort in using technical terms. It establishes authority. It shows that you are an expert. But it also creates a wall. If a reader has to Google a term just to understand your sentence, you have lost them. The goal of content marketing is to lower the barrier to entry, not to raise it.

Many organizations have found that their best-performing content is often the simplest. It is the post that explains a complex concept using an analogy that anyone can understand. It is the video that skips the technical deep dive and focuses entirely on the customer's pain point.

To overcome this, technical founders must learn to let go of the need for total control. They must accept that their first draft will be flawed. They must learn to write for the reader, not for their own ego. The goal is to start the conversation, not to write the final word on the subject. Once you publish, you can iterate, improve, and refine based on real feedback. But you cannot iterate on a file that never leaves your hard drive.

The Strategy Gap: Why "Just Posting" Doesn't Work

Closely related to perfectionism is the lack of a coherent strategy. Many technical founders view content marketing as a sporadic activity--a few posts here, a tweet there, and a newsletter update whenever inspiration strikes. They treat it as a hobby rather than a business function.

This is the "Strategy Gap." Without a plan, content marketing becomes a random walk through the internet, hoping to stumble upon a customer. It is inefficient and unsustainable.

A true content strategy involves understanding your audience deeply. Who are they? What are their pain points? What questions are they asking? Where do they hang out online? Once you have this intelligence, you can create a content calendar that addresses these specific needs over time.

It is not enough to simply broadcast that you have launched a new feature. That is "broadcasting," not "marketing." Real marketing involves educating, entertaining, and engaging. It involves solving a problem for the reader before they even realize they have it.

For a technical founder, this might mean creating a series of "how-to" guides that solve a specific technical problem that your software addresses. It might mean producing case studies that demonstrate how other companies have used your tools to save money or increase efficiency. It means creating content that is valuable in itself, regardless of whether the reader ever buys your product.

The Strategy Gap is also visible in the lack of consistency. Technical founders often burn out because they try to do it all at once. They decide to start a blog, write a weekly newsletter, post on LinkedIn three times a day, and start a podcast. The result is usually a hasty, low-quality effort across all channels.

A better approach is to pick one or two channels where your audience actually hangs out and commit to them. Focus on quality and consistency over quantity. Build a library of assets that you can repurpose and update over time. This is not a sprint; it is a marathon.

The Blueprint for Conversion: Moving from Code to Conversation

So, how do you fix this? How do you move from a struggling technical founder to a content-savvy leader? The transformation begins with a mindset shift. You must stop thinking like a developer and start thinking like a publisher.

The first step is to adopt the "Writer's Mindset." This means approaching your writing with empathy. Before you write a single word, ask yourself: "Who is this for?" and "What is their problem?" Write as if you are having a one-on-one conversation with a single person in a coffee shop. Use clear, simple language. Avoid jargon unless you can explain it in plain English.

The second step is to treat content like a product. Just as you would test your software for bugs, you should test your content. Look at your analytics. Which posts are getting the most engagement? Which ones are driving traffic to your website? Use this data to inform your future content strategy. If a technical deep dive post isn't getting shares, maybe it's too dry. If a "behind the scenes" post is going viral, maybe that is your niche.

Third, you must integrate content creation into your development cycle. Do not wait until the product is finished to start talking about it. Start writing about the problems you are solving while you are still in the design phase. This not only builds anticipation but also helps you clarify your own thinking. Writing about your vision forces you to articulate it clearly, which is essential for your own understanding.

Finally, you need to stop trying to be perfect and start trying to be helpful. The most successful technical brands are those that provide genuine value to their community. They answer questions. They share knowledge. They admit when they don't know something. This builds trust. And in business, trust is the currency that buys customers.

Your Next Move: Stop Building, Start Talking

The technical founder who understands this truth will have a significant advantage. They will not just build a product; they will build a community. They will not just write code; they will write copy that sells. They will realize that the best product in the world is useless if no one knows it exists.

The journey from isolation to connection is challenging. It requires learning new skills and stepping out of your comfort zone. It requires admitting that you don't have all the answers and that your audience might know things you don't. But the rewards are immense. You build a brand that resonates. You create a loyal following that advocates for your product. You turn your technical expertise into a powerful marketing asset.

So, the next time you sit down to write, put down the technical documentation. Pick up the pen. Or open the laptop. Write for the human being on the other side of the screen. Explain the value. Tell the story. And most importantly, listen to the response.

Your customers are waiting for you to stop building in a vacuum and start talking to them. Are you ready to have the conversation?

External Resources for Further Reading

HubSpot: The Beginner's Guide to Content Marketing - A comprehensive overview of what content marketing is and why it matters for businesses of all sizes.
Neil Patel: How to Write a Blog Post That Converts - Practical advice on structuring your content to engage readers and drive action.
Harvard Business Review: The Role of Storytelling in Business - Insights into how narrative can be used to build brand identity and connect with audiences.
Moz: The Beginner's Guide to SEO - Understanding how content fits into the broader digital marketing ecosystem and search engine visibility.

gpt-image-2 API Developer Guide: Pricing, Thinking Mode, and Production Integration (2026)

tokenmixai — Thu, 23 Apr 2026 05:31:08 +0000

gpt-image-2 API Developer Guide: Pricing, Thinking Mode, and Production Integration (2026)

OpenAI announced gpt-image-2 on April 21, 2026 — but the official API doesn't open to developers until early May 2026. That gap between "announced" and "shippable" is exactly when developers need to architect, budget, and prototype. This guide covers everything a developer needs to know now: the published pricing math, the Instant/Thinking mode trade-offs, the multi-image API contract, pre-release access via fal.ai and apiyi, and a cost calculator template you can drop into a project today. Code examples in Python, all working against either the pre-release third-party endpoints or the OpenAI API once it goes live in early May. TokenMix.ai tracks gpt-image-2 alongside 50+ image models for teams comparing inference cost and routing per task.

What Developers Need to Know in One Page
Pricing Breakdown: Per-Token, Per-Image, Per-Workflow
Instant vs Thinking Mode: When to Use Which
Pre-Release API Access (fal.ai, apiyi)
Code: Single Image Generation
Code: 8-Image Consistent Series
Code: Image Editing / Inpainting
Cost Calculator Template
Migrating from gpt-image-1 / DALL-E 3
Rate Limits, Errors, and Production Gotchas
FAQ

What Developers Need to Know in One Page {#tldr}

Topic	Quick answer
Model name	`gpt-image-2`
Modes	`instant` (default), `thinking` (opt-in)
Released	April 21, 2026 (ChatGPT/Codex)
API GA	Early May 2026 (OpenAI direct)
Pre-release access	fal.ai, apiyi (third-party hosted)
Max resolution	2000px long edge
Aspect ratios	1:1, 3:2, 2:3, 16:9, 9:16, 3:1, 1:3
Multi-image per call	Up to 8 with character/object continuity
Web search grounding	Yes (in Thinking mode)
Per-image cost	~$0.21 at 1024×1024 HD standard
Token-level pricing	$5/$10/$8/$30 per MTok (text-in / text-out / image-in / image-out)
SDK	Same `openai` Python/Node client, new endpoint pattern
Image editing	Supported (same endpoint family as gpt-image-1)
Content policy	Same as ChatGPT — no NSFW, no real persons, no copyrighted characters

If you're an existing OpenAI image API user, the migration is mechanical: change model="gpt-image-1" to model="gpt-image-2", optionally add quality="thinking" for complex prompts, optionally request n=8 for consistent series.

Pricing Breakdown: Per-Token, Per-Image, Per-Workflow {#pricing}

OpenAI pricing for gpt-image-2 (per official pricing page):

Direction	$/M tokens
Input text	$5
Output text	$10
Input image	$8
Output image	$30

Why per-token instead of per-image?

Because gpt-image-2 charges for the planning work (prompt comprehension, reasoning steps, web-search results) plus the actual pixel output. A simple "cat on a chair" costs less than "magazine cover with 5 cover lines and a hero photo." Per-token billing captures that.

Per-image cost cheat sheet

Approximate cost per image, assuming a 50-token text prompt:

Resolution	Mode	Approximate cost
1024×1024	Instant	$0.10
1024×1024	Thinking	$0.21
1024×1024 HD	Instant	$0.21
1024×1024 HD	Thinking	$0.40
1792×1024	Instant	$0.18
1792×1024	Thinking	$0.35
2000×1125 (max)	Thinking	~$0.50

Workflow cost examples

Workflow	Calls	Estimated cost
Single hero image, 1024×1024 HD	1	$0.21
8-image storyboard, 1024×1024	1 (n=8)	~$1.50
Magazine cover, Thinking mode, 2000×1125	1	~$0.50
Daily 100 social posts, 1024×1024 Instant	100	~$10/day
Marketing campaign: 50 multilingual variants, Thinking, HD	50	~$20

For teams generating thousands of images per day, TokenMix.ai tracks live pricing across gpt-image-2, Imagen 4 Ultra, Seedream 5, FLUX, and others — and lets you route per task (text-heavy → gpt-image-2, stylized → Midjourney, budget → FLUX).

Instant vs Thinking Mode: When to Use Which {#modes}

Aspect	Instant	Thinking
Latency	3-5s	10-30s
Cost multiplier	1×	2-3×
Best for	Single concept, short prompts, casual content	Multi-element prompts, infographics, structured layouts, multilingual text, web-grounded content
When it self-verifies	No	Yes — checks output and re-renders if needed
Web search	No	Yes
Multi-image consistency (n=8)	Available, but quality lower	Recommended — planning step ensures continuity

Decision tree

Is the prompt > 30 words OR contains structured info (text, layout, multilingual)?
├── Yes → Thinking mode
└── No
    └── Is web-grounded data needed (current weather, real maps, etc.)?
        ├── Yes → Thinking mode
        └── No
            └── Is multi-image continuity required (n > 1)?
                ├── Yes → Thinking mode
                └── No → Instant mode

In practice: default Instant, opt into Thinking when the prompt has structure or multi-image requirements.

Pre-Release API Access (fal.ai, apiyi) {#pre-release}

OpenAI's official API GA is early May 2026. For teams that need to prototype now, two third-party providers expose pre-release gpt-image-2 endpoints:

fal.ai

OpenAI partner, hosts gpt-image-2 at fal-ai/openai/gpt-image-2:

import fal_client

result = fal_client.subscribe(
    "fal-ai/openai/gpt-image-2",
    arguments={
        "prompt": "Magazine cover, hero photo of a coffee shop, headline 'Brew Renaissance' in bold serif",
        "image_size": "portrait_16_9",
        "mode": "thinking",
    },
)
print(result["images"][0]["url"])

apiyi.com

Aggregator with gpt-image-2 access at fixed per-call pricing (~$0.03/call standard, varies):

from openai import OpenAI

client = OpenAI(
    api_key="your-apiyi-key",
    base_url="https://api.apiyi.com/v1",
)

resp = client.images.generate(
    model="gpt-image-2",
    prompt="...",
    size="1024x1024",
    quality="hd",
    n=1,
)
print(resp.data[0].url)

Caveat: pre-release endpoints have variable rate limits, occasional outages, and may not match the final OpenAI API contract exactly. Use for prototyping, not production.

Code: Single Image Generation {#code-single}

Once OpenAI's API opens (early May 2026), the canonical pattern:

from openai import OpenAI

client = OpenAI(api_key="sk-...")

response = client.images.generate(
    model="gpt-image-2",
    prompt="Restaurant menu cover, 'Saigon Street Food', dark wood texture background, "
           "bilingual Vietnamese-English, photographic style",
    size="1024x1536",      # portrait
    quality="hd",
    quality_mode="instant" # or "thinking"
)

image_url = response.data[0].url
# or response.data[0].b64_json if using response_format="b64_json"

Saving the image

import requests

img_data = requests.get(image_url).content
with open("menu_cover.png", "wb") as f:
    f.write(img_data)

Inline base64 (avoid the URL fetch step)

import base64

response = client.images.generate(
    model="gpt-image-2",
    prompt="...",
    response_format="b64_json",
)

img_bytes = base64.b64decode(response.data[0].b64_json)
with open("output.png", "wb") as f:
    f.write(img_bytes)

Code: 8-Image Consistent Series {#code-multi}

The flagship feature. Single API call, 8 outputs, character/scene continuity preserved:

response = client.images.generate(
    model="gpt-image-2",
    prompt=(
        "8-panel storyboard for a 30-second ad: a young engineer arrives at a coffee shop, "
        "opens a laptop, codes intensely, has an aha moment, ships a feature, celebrates, "
        "shares with team, day ends. Consistent character (woman, mid-20s, glasses, purple hoodie), "
        "consistent setting (warm-lit coffee shop). Cinematic style."
    ),
    n=8,
    size="1792x1024",
    quality_mode="thinking",  # required for true consistency
)

for i, img in enumerate(response.data):
    img_data = requests.get(img.url).content
    with open(f"storyboard_{i+1}.png", "wb") as f:
        f.write(img_data)

Use cases unlocked

Use case	n	Mode
Comic strip	4-8	Thinking
Product variations (colors/angles)	4-8	Thinking
Sequential tutorial steps	4-8	Thinking
A/B creative variants	2-4	Instant or Thinking
Manga panel sequence	6-8	Thinking

Code: Image Editing / Inpainting {#code-edit}

Same endpoint pattern as gpt-image-1, with the new model:

with open("original.png", "rb") as image_file, open("mask.png", "rb") as mask_file:
    response = client.images.edit(
        model="gpt-image-2",
        image=image_file,
        mask=mask_file,
        prompt="Replace the background with a sunset beach, keep the subject",
        size="1024x1024",
    )

print(response.data[0].url)

The mask.png should be the same dimensions as image.png with transparent areas marking what to edit.

Cost Calculator Template {#cost-calc}

Drop-in cost estimator for budgeting:

PRICING = {
    "input_text_per_mtok": 5.00,
    "output_text_per_mtok": 10.00,
    "input_image_per_mtok": 8.00,
    "output_image_per_mtok": 30.00,
}

def estimate_cost(
    prompt_tokens: int,
    output_image_tokens: int,
    n_images: int = 1,
    thinking_mode: bool = False,
    input_image_tokens: int = 0,
):
    """Rough cost estimate in USD."""
    # Thinking mode adds reasoning tokens (rough estimate: 2-3x input)
    reasoning_multiplier = 2.5 if thinking_mode else 1.0

    input_text_cost = prompt_tokens * reasoning_multiplier * PRICING["input_text_per_mtok"] / 1_000_000
    input_image_cost = input_image_tokens * PRICING["input_image_per_mtok"] / 1_000_000
    output_image_cost = (
        output_image_tokens * n_images * PRICING["output_image_per_mtok"] / 1_000_000
    )

    return {
        "input_text": round(input_text_cost, 4),
        "input_image": round(input_image_cost, 4),
        "output_image": round(output_image_cost, 4),
        "total": round(input_text_cost + input_image_cost + output_image_cost, 4),
    }


# Example: HD 1024x1024, Thinking mode, single image
# Rough token mapping: 1024x1024 HD ≈ 6800 output tokens
print(estimate_cost(
    prompt_tokens=80,
    output_image_tokens=6800,
    n_images=1,
    thinking_mode=True,
))
# {'input_text': 0.001, 'input_image': 0.0, 'output_image': 0.204, 'total': 0.205}

# Example: 8-image storyboard, Thinking
print(estimate_cost(
    prompt_tokens=200,
    output_image_tokens=4500,  # standard 1024x1024
    n_images=8,
    thinking_mode=True,
))
# {'input_text': 0.0025, 'input_image': 0.0, 'output_image': 1.08, 'total': 1.0825}

For per-call billing visibility across providers (gpt-image-2, Imagen, FLUX, Seedream), TokenMix.ai exposes a unified usage dashboard.

Migrating from gpt-image-1 / DALL-E 3 {#migration}

From gpt-image-1

# Old
client.images.generate(model="gpt-image-1", prompt=...)

# New (mechanical change)
client.images.generate(model="gpt-image-2", prompt=...)

# Optional: opt into Thinking mode for complex prompts
client.images.generate(
    model="gpt-image-2",
    prompt=...,
    quality_mode="thinking",
)

# Optional: request multi-image
client.images.generate(
    model="gpt-image-2",
    prompt=...,
    n=8,
    quality_mode="thinking",
)

From DALL-E 3

# Old
client.images.generate(model="dall-e-3", prompt=..., size="1024x1024")

# New
client.images.generate(model="gpt-image-2", prompt=..., size="1024x1024")

The response shape (response.data[0].url / b64_json) is unchanged. Existing code that handles the response will work without modification.

Things to retest after migration

Prompt sensitivity — gpt-image-2 follows prompts more literally than DALL-E 3. Prompts that worked via "vibes" may need to be more specific
Negative prompts — neither model exposes formal negative prompts, but gpt-image-2's reasoning can interpret natural-language exclusions ("no people in the scene") more reliably
Style anchors — gpt-image-2 leans more "photorealistic / commercial" by default; explicitly request style ("watercolor", "anime", "low-poly 3D") if needed

Rate Limits, Errors, and Production Gotchas {#production}

Based on the published OpenAI rate limit structure (subject to change at GA):

Tier	Images per minute	Tokens per minute
Tier 1	5	100K
Tier 2	50	500K
Tier 3+	200+	2M+

Common errors

from openai import (
    OpenAI, RateLimitError, APITimeoutError, BadRequestError, APIError,
)
import time, random

def generate_with_retry(client, **kwargs):
    for attempt in range(4):
        try:
            return client.images.generate(**kwargs)
        except RateLimitError:
            wait = (2 ** attempt) + random.random()
            time.sleep(wait)
        except APITimeoutError:
            # Thinking mode can timeout on very complex prompts
            if "quality_mode" in kwargs and kwargs["quality_mode"] == "thinking":
                kwargs["quality_mode"] = "instant"  # downgrade and retry
            else:
                raise
        except BadRequestError as e:
            # Often: prompt violates content policy
            print(f"Bad request: {e}")
            raise
        except APIError as e:
            if attempt == 3:
                raise
            time.sleep(2 ** attempt)
    raise RuntimeError("All retries exhausted")

Production gotchas

Timeout default is 60s — Thinking mode can hit this on complex 8-image batches. Set explicit timeout=120 for n=8 + Thinking
Image URLs expire — Per OpenAI's policy, hosted URLs expire in ~2 hours. Always download or store the b64_json variant for long-term assets
Content policy blocks return 400, not 403 — Catch BadRequestError specifically and parse the message for "content_policy" before retrying
Cost surprise on Thinking + n=8 — A single n=8 Thinking call can cost $1-2. Add a hard budget check before invoking
Token estimation is hard — OpenAI doesn't publish a tokenizer for image outputs. Use observed average tokens-per-resolution from initial calls and budget conservatively

FAQ {#faq}

Q: When can I use gpt-image-2 in production?
A: OpenAI's API GA is early May 2026. For pre-GA prototyping, fal.ai and apiyi expose endpoints today, but with variable reliability. For mission-critical work, wait for GA.

Q: How do I integrate gpt-image-2 into a multi-model image gen system?
A: Use the OpenAI-compatible image endpoint. The model parameter is the only thing that changes between gpt-image-2, Imagen 4 Ultra (via Vertex AI compat), Seedream 5, etc. A unified API gateway like TokenMix.ai abstracts the provider differences.

Q: Can I fine-tune gpt-image-2?
A: Not at launch. OpenAI hasn't announced fine-tuning for the gpt-image series.

Q: Does gpt-image-2 support function calling / tool use during generation?
A: In Thinking mode, the model can invoke web search internally. External tool use (custom functions) is not exposed in the image generation API.

Q: What's the maximum prompt length?
A: Officially documented at 32,000 input tokens, but in practice prompts over ~500 tokens see diminishing returns. For long context, use the structure-aware Thinking mode.

Q: Does gpt-image-2 work for image-to-image transformations?
A: Yes, via the images.edit endpoint with an input image and optional mask. Style transfer, inpainting, and variations all work. Pure image-to-image generation (no mask) is also supported.

Q: How do I prevent gpt-image-2 from refusing valid prompts?
A: Avoid: real-person likenesses, copyrighted characters/brands, NSFW, violence. Be specific about safety-relevant elements ("a fictional character", "abstract symbol"). If you hit unjustified refusals, file a feedback ticket via OpenAI's developer console.

Q: Should I switch from Midjourney for production?
A: Depends on workload. For text-heavy, multi-image, or multilingual content — yes, gpt-image-2 wins on quality and unblocks workflows that were impossible. For pure stylized art, Midjourney V7 still has the edge. Many teams will run both.

Sources

By TokenMix Research Lab · Updated 2026-04-23

The Primeagen's '99': A New Approach to AI in Code Editors

Stelixx Insider — Thu, 23 Apr 2026 05:20:46 +0000

The Perpetual Struggle: Why Current AI Integrations in Code Editors Often Fail

Many developers have experienced the frustration of integrating AI assistants directly into their code editors. The common pitfalls include:

Clunky User Experience: AI tools that feel out of place and disrupt the natural coding flow.
Lack of Contextual Understanding: AI that doesn't grasp the nuances of your specific codebase, leading to irrelevant suggestions.
Distraction Over Assistance: The AI becoming more of a hindrance than a help.

This is precisely the problem that The Primeagen's "99" project aims to solve. By focusing on intuitive design and deep contextual awareness, "99" is poised to redefine how developers interact with AI, making it a true productivity enhancer.

This open-source initiative represents a significant step forward in making AI an indispensable and seamless part of the developer's toolkit. We're excited to see the community's contribution and evolution of this project.

Stelixx #StelixxInsights #IdeaToImpact #AI #BuilderCommunity #CodeEditorAI #DevCommunity #OpenSource

Best resources to learn game development with Node.js

Stack Overflowed — Thu, 23 Apr 2026 05:20:38 +0000

Every few months, someone asks me, What are the best resources to learn game development with Node.js? The question usually comes from one of two places. Either someone has fallen in love with JavaScript and wants to build games without leaving the ecosystem, or they’ve seen that multiplayer games often use Node on the backend and want to understand how it all fits together.

The tricky part is that Node.js is not a game engine. It doesn’t render sprites. It doesn’t handle physics out of the box. It doesn’t manage scenes. So if you approach the question assuming Node will teach you “game development” the way Unity or Unreal does, you’ll feel confused.

But if you reframe the question and understand what Node is actually good at, the learning path becomes clearer.

Why Node.js is suited for certain types of games

Node.js shines in one specific domain of game development: real-time, networked systems.

Think:

Multiplayer backends
Matchmaking services
Chat systems
Game state synchronization

The event-driven, non-blocking architecture of Node makes it well-suited for handling many concurrent connections.

Node is ideal for:

Real-time multiplayer servers using WebSockets
Turn-based backend logic
Leaderboards and persistent APIs
Matchmaking and session management

It is not ideal for:

Graphics-heavy engines
CPU-intensive simulations

This distinction prevents wasted effort.

Frontend game engines vs. backend game logic

A common confusion is mixing frontend and backend responsibilities.

Frontend (Client-side)

Handles:

Rendering
Animation loops
Input handling
Physics simulation

Backend (Server-side with Node.js)

Handles:

Player authentication
State synchronization
Anti-cheat validation
Matchmaking
Persistent storage

Node.js lives entirely in the backend layer.

In multiplayer systems:

The client renders
The server validates and controls

That authority model is critical.

Why foundational Node knowledge matters first

Before using multiplayer frameworks, you must understand:

Event loop
Asynchronous programming
Streams
Networking basics

Without this:

Blocking operations will break performance
Async logic becomes unmanageable
Networking becomes fragile

Educative – Learn Node.js

This course focuses on:

Core Node architecture
Async patterns
HTTP servers
Modular design

It is not game-specific, but it builds the foundation required for multiplayer systems.

How different resource types complement each other

Game development with Node requires combining multiple resource types.

Resource Type	Focus	Strength	Best For	Limitations
Structured Node Course (e.g., Educative)	Core architecture	Clear progression, strong fundamentals	Beginners building backend knowledge	Not game-specific
Official Node & WebSocket Docs	API precision	Deep technical reference	Refining networking understanding	Requires prior knowledge
Game Networking Tutorials	Real-time examples	Shows integration patterns	Bridging theory and practice	Often oversimplified
Open-Source Multiplayer Projects	Real-world architecture	Exposure to production patterns	Intermediate learners	Can be overwhelming

Each resource serves a different purpose. None replace each other.

A narrative walkthrough: from Node basics to multiplayer server

Let’s walk through a realistic progression.

Step 1: Learn Node fundamentals

HTTP servers
Async callbacks
Modules
API structure

Step 2: Build a WebSocket system

Create a chat server
Handle persistent connections
Broadcast messages

Step 3: Build a simple real-time prototype

Shared whiteboard or counter
Introduce state synchronization
Encounter race conditions

Step 4: Introduce server authority

Validate player actions
Separate logic layers
Manage state centrally

Step 5: Build a simple multiplayer game

Real-time position updates
Tick rates
Latency handling
Prediction techniques

At this stage, you move from coding to system design thinking.

When you’re ready to build a real-time multiplayer server

You’re ready when:

You understand the event loop deeply
You avoid blocking operations
You handle shared state safely
You understand authoritative server models
You can reason about scaling

These are backend engineering skills, not game engine skills.

Mixing theory and practical experimentation

A common mistake is relying only on quick tutorials.

Problems you’ll face in real systems:

Reconnection handling
Server crashes
Cheating prevention
Horizontal scaling

To handle these:

Theory → gives mental models
Practice → reveals real-world issues

You need both.

Choosing your learning path intentionally

Your path depends on your starting point.

If you’re new to backend development:

Start with Node fundamentals
Focus on async patterns and architecture

If you know Node but not networking:

Learn WebSockets
Study state synchronization
Explore distributed systems

If you know both:

Build real projects
Create matchmaking systems
Design multiplayer prototypes

At every stage, ask:

Am I copying patterns, or do I understand them?

Bringing it back to the core question

If someone asks again, What are the best resources to learn game development with Node.js?, the answer is not a simple list.

It’s a layered approach:

Strengthen Node fundamentals
Learn networking concepts
Experiment with real-time systems
Study architecture through projects

Node is not a game engine. It is a coordination engine.

When you treat it that way, your learning path becomes clear.

Conclusion

The best resources are not the flashiest ones. They are the ones that:

Build strong fundamentals
Improve reasoning
Expose real-world complexity

Game development with Node is really about building distributed systems for real-time interaction.

And the moment you shift from syntax to architecture—that’s when real learning begins.

Building an AI Helpdesk SaaS with Agentic Automation

Datheon — Thu, 23 Apr 2026 05:19:12 +0000

Hey devs 👋

I just built a full-stack AI SaaS helpdesk platform focused on automation, intelligent ticket handling, and what many are starting to call agentic AI systems.

🚀 The Idea

Most support systems are reactive.

I wanted something that:

Understands tickets automatically
Makes decisions
Takes actions without constant human input

Inspired by platforms like Deptheon-style architectures, I designed a system that behaves more like an intelligent operator than just a tool.

🧱 Tech Stack

FastAPI + PostgreSQL (backend)
React + TypeScript + Tailwind (frontend)
Ollama (Llama3) for local AI
n8n for automation (29 workflows 🤯)
Stripe for billing

⚙️ What It Does

Every ticket is automatically:

Categorized & prioritized
Sentiment analyzed
Checked for duplicates
Assigned to the best available agent

Then AI:

Generates replies
Detects frustrated users
Auto-resolves common issues
Builds a knowledge base

🤖 Agentic Layer

Instead of simple LLM calls, the system:

Observes
Decides
Acts

That’s where the real power comes in.

🔁 Automation

With n8n, I implemented:

SLA breach alerts
Churn prediction
Incident detection
Auto follow-ups
Smart ticket routing

🧠 What I Learned

AI alone isn’t enough — orchestration is everything
Automation + LLMs = real leverage
“Agentic systems” are structured decision systems (not magic)
Local AI is underrated

📊 Final Thought

We’re moving from:
AI features → AI systems that operate businesses

And that changes everything.

Would love feedback or ideas from anyone building in AI / SaaS 🙌

The Nine-Year Journey to the Orca Emoji (U+1FACD) — How a Single Character Moved the World

upa_rupa — Thu, 23 Apr 2026 05:18:26 +0000

I love orcas, so I always felt a bit sad that while we had whale (🐋) and dolphin (🐬) emojis, there was no orca. Then recently, I came across news that the orca emoji would be introduced in iOS 26.4^[1]. Since emoji aren't an Apple-proprietary thing — they're defined by an international standard called Unicode — I knew this had to be a bigger story. So I dug in.

What I found was the story behind the new orca emoji 🫍: a nine-year campaign by people around the world pushing for its adoption into the Unicode standard.

Basic Info

Field	Details
Code Point	U+1FACD
Name	ORCA
Block	Symbols and Pictographs Extended-A
Standard Version	Unicode 17.0 / Emoji 17.0
Release Date	September 9, 2025

This emoji was added as a new standalone code point^[2] — not expressed by combining existing emoji, but assigned its own unique code: U+1FACD.

2016–2017: Voices Rise Around the World

The orca emoji story begins well before any official proposal, and in multiple places at once.

In August 2016, Jökull Ingi Þorvaldsson from Iceland started an online petition on Change.org called "Make a Killer Whale Emoji," asking Apple to add an orca emoji^[4]. It gathered 39 signatures.

The following February (2017), Christoph Päper, a Unicode contributor from Germany, opened an issue titled "Orca emoji" on the GitHub Unicode proposals tracker (Crissov/unicode-proposals)^[3]. His point: we have whale (🐋) and dolphin (🐬) emoji — why not orca? The issue included a link to the Change.org petition above.

The voices were there. But voices alone don't create emoji. A formal proposal had to be submitted to the Unicode Consortium.

February 2019: A Third Person Steps Up

In 2019, a Spanish developer named Marcos Del Sol Vives turned these feelings into a formal proposal^[5].

On February 20th, Marcos submitted a proposal for the orca emoji to the Unicode Consortium's Emoji Subcommittee (ESC). He had no connection to Jökull in Iceland or Christoph in Germany — he was a third, independent voice.

Then in September 2020, Lukas Ewert in Germany (also independently) launched another Change.org petition, "Make Orcas an Emoji," collecting 356 signatures^[15].

People around the world, strangers to each other, were all asking for the same thing: an orca emoji.

Marcos's proposal followed the format Unicode requires and made a compelling case^[6].

Search Popularity Comparison

Using Bing search trends, Marcos showed that "orca" had roughly the same search popularity as "elephant." Elephants already have an emoji (🐘) — orcas don't. He quantified the gap.

No Existing Emoji Covers It

Unicode's proposal review includes an "exclusion factors" section, where proposers must argue why their submission shouldn't be excluded. Marcos addressed this directly^[6].

"Can't an existing emoji substitute?" — No. Orcas are commonly called "killer whales" but are scientifically members of the dolphin family, and they look quite different from whales. "Too specialized?" — Pufferfish, crickets, and swans already have emoji, so orca can't be considered too specialized. "Just a passing trend?" — Orcas have existed on Earth for about 11 million years, the proposal notes.

Sample Images

Following Unicode Consortium requirements, Marcos prepared sample images at 18×18 and 72×72 pixels, in both black-and-white and color.

2019–2023: The Gate Is Closed

From here, Marcos's proposal entered a long wait.

The proposal was sent in 2019. But the formal document number L2/24-249 wasn't registered in the Unicode document registry until 2024^[6]. There is no orca-related document anywhere in the 2019 Document Register^[7].

So what happened during those five years? Looking into it, what emerged wasn't simple neglect — it was a deliberate decision on Unicode's part.

The Iron Rule: Once Added, Never Removed

First, some background: Unicode has an absolute rule called the Stability Policy^[17].

Once a character is encoded, it will not be moved or removed.

This means that once a code point is assigned, it stays there as long as humanity uses this standard — forever. Mistakes cannot be undone. This is the foundation of Unicode's caution around adding emoji.

A Strategic Pause — Shifting to Quality Over Quantity

In 2020, the COVID-19 pandemic pushed back the Unicode 14.0 release by six months^[2]. Then in autumn 2022, the UTC (Unicode Technical Committee) announced that Unicode 15.1 would be a limited release.

ESC chair Jennifer Daniel saw this as an opportunity. Her January 2023 blog post, "Breaking the Cycle"^[18], stated:

emoji categories are about to hit or have hit a level of saturation.

the ESC approves fewer and fewer emoji proposals every year.

The ESC used this pause to tackle longstanding issues: unifying skin tone variations, redesigning family emoji, and improving bidirectional text support. They also decided to temporarily delay the Unicode 17.0 submission window until April 2024^[18].

This wasn't a shutdown from neglect. It was a deliberate pause to redefine the emoji addition process itself.

Marcos's Proposal, Waiting at the Gate

There is no record of the orca emoji being rejected. It doesn't appear on Charlotte Buff's list of rejected emoji proposals^[10], nor in the official Unicode non-approval notice archive^[11].

Marcos's proposal wasn't denied. The gate was simply closed.

2024: The Gate Reopens

On April 2, 2024, submissions reopened with new guidelines^[8]. ESC chair Jennifer Daniel announced the reopening^[9].

When the gate opened, Marcos's proposal — waiting since 2019 — finally received its formal document number, L2/24-249^[6]. Later that year in November, the ESC proposed 164 new emoji candidates to the UTC, including the orca^[12]. Of those 164: 9 new code points and roughly 155 skin tone variations of existing emoji. One of the new code points — the Apple Core — was ultimately withdrawn, and the remaining 163 were approved as Emoji 17.0.

No objections were submitted during the Public Review Issue (PRI #515) for Emoji 17.0 candidates^[16].

September 9, 2025: Official Adoption

As part of Unicode 17.0 / Emoji 17.0, the orca emoji was officially approved^[2]. About nine years from the first online petition; about six and a half years from Marcos's proposal.

Marcos himself hasn't spoken publicly much about the details of this journey. His site orca.pet records the fact of the proposal and the fact of adoption — simply^[5].

The Emoji Approval Process: Open, but Careful

Unicode's emoji approval process is designed to be transparent^[13].

Submit a proposal: Anyone can submit an emoji proposal
ESC review: The Emoji Subcommittee evaluates proposals and decides whether to recommend them to the UTC
UTC deliberation: Discussed by the technical committee; meeting notes are published
Draft candidate list: Before final approval, a candidate list is published as a Public Review Issue (PRI), open for public feedback, which is also published^[16]
Official release: Released as a new version of the Unicode standard

All proposals are published as PDFs on unicode.org and available for anyone to read^[6].

Given that an assigned code point can never be removed, this caution has good reason. As the orca's case shows, years between proposal and adoption aren't unusual. But that's not negligence — it's a reflection of the weight of defining a standard that will be used, permanently, across the world.

Platform Support Status (as of March 2026)

Platform	Status
Google Noto Color Emoji	Supported (v2.051, released September 12, 2025)^[14]
Apple (iOS / macOS)	In beta with iOS 26.4 / macOS 26.4; stable release expected March–April 2026^[1]
X (formerly Twitter)	Supported (Twemoji v17.0)
Microsoft (Windows)	Not yet supported; as of March 2026, just reached Emoji 16.0 support

Unicode defines the code point and meaning, but the visual design is left to each platform (Apple, Google, Samsung, etc.). That's why the same U+1FACD looks different on iPhone versus Android.

Display Test with Noto Color Emoji

This article loads Google's Noto Color Emoji font to test rendering of the new orca emoji.

🫍

Even if your browser or OS doesn't support Unicode 17.0 emoji yet, you should see it rendered via Noto Color Emoji. If you can see a large orca above, it's working.

Summary

The orca emoji (🫍) was born from independent voices in Iceland, Germany, and Spain — and took nine years to make it into the Unicode standard
Proposer Marcos Del Sol Vives built a case backed by search data and comparative arguments
The five-year gap wasn't neglect — it was a deliberate pause for Unicode to confront emoji saturation and redefine the addition process
Unicode's emoji approval process is transparent, but the Stability Policy demands care

Every emoji we casually use has a story behind it. And those stories are often less about triumph than about patience and a series of coincidences stacking up over time.

References

iPhone Mania, "iOS26.4で利用可能になる新絵文字のデザインが明らかに！ (Japanese)" March 10, 2026. https://iphone-mania.jp/ios-600850/
The Unicode Blog, "Unicode 17.0 Release Announcement," September 9, 2025. http://blog.unicode.org/2025/09/unicode-170-release-announcement.html
Crissov/unicode-proposals, "Issue #103: Orca emoji," GitHub, February 5, 2017. https://github.com/Crissov/unicode-proposals/issues/103
Jökull Ingi Þorvaldsson, "Make a Killer Whale Emoji," Change.org, August 2016. https://www.change.org/p/apple-make-a-killer-whale-emoji-in-apple-s-emoji-board
Marcos Del Sol Vives, "Orca emoji," orca.pet. https://orca.pet/emoji/
Marcos Del Sol Vives, "Proposal for Orca Emoji," Unicode Document L2/24-249, 2024. https://www.unicode.org/L2/L2024/24249-orca-emoji.pdf
The Unicode Consortium, "UTC Document Register — 2019." https://www.unicode.org/L2/L2019/Register-2019.html
The Unicode Blog, "Emoji Submissions Intake Process Re-opening," March 2024. http://blog.unicode.org/2024/03/emoji-submissions-intake-process-re.html
Jennifer Daniel, "Emoji submissions re-opening," Substack. https://jenniferdaniel.substack.com/p/emoji-submissions-re-opening-april
Charlotte Buff, "Rejected Emoji Proposals." https://charlottebuff.com/unicode/misc/rejected-emoji-proposals/
The Unicode Consortium, "Archive of Notices of Non-Approval." https://www.unicode.org/alloc/nonapprovals.html
Emojipedia Blog, "What's New In Unicode 17.0." https://blog.emojipedia.org/whats-new-in-unicode-17-0/
The Unicode Consortium, "Submitting Emoji Proposals." https://unicode.org/emoji/proposals.html
Emojipedia Blog, "Google Debuts Emoji 17.0 Support." https://blog.emojipedia.org/google-debuts-emoji-17-0-support/
Lukas Ewert, "Make Orcas an Emoji," Change.org, September 2020. https://www.change.org/p/apple-make-orcas-an-emoji
The Unicode Consortium, "PRI #515: Unicode Emoji 17.0 Alpha Repertoire." https://www.unicode.org/review/pri515/
The Unicode Consortium, "Unicode Character Encoding Stability Policies." https://www.unicode.org/policies/stability_policy.html
Jennifer Daniel, "Breaking the Cycle," The Unicode Blog, March 8, 2024 (originally published January 17, 2023). http://blog.unicode.org/2024/03/breaking-cycle.html

This article was originally published in Japanese at archelon-inc.jp.

シャチ絵文字（U+1FACD）がUnicodeに採用されるまで — 1文字のために世界が動いた9年越しの軌跡

upa_rupa — Thu, 23 Apr 2026 05:18:22 +0000

シャチ絵文字（U+1FACD）がUnicodeに採用されるまで — 1文字のために世界が動いた9年越しの軌跡

私はシャチが好きである。なので、クジラ（🐋）やイルカ（🐬）の絵文字はあるのにシャチがないことを残念に思っていた。

しかし最近、iOS 26.4からシャチの絵文字が追加されるというニュースを目にした^[1]。絵文字はApple独自のものではなくUnicodeという国際標準で定められているはずだから、これはもっと大きな話のはずだ — そう思って調べてみた。

すると見えてきたのは、新しいシャチの絵文字 🫍 の裏にある、9年にわたって世界各地の人々がUnicode標準への採用を求め続けた物語だった。

シャチ絵文字の基本情報

項目	内容
コードポイント	U+1FACD
名称	ORCA
収録ブロック	Symbols and Pictographs Extended-A
標準バージョン	Unicode 17.0 / Emoji 17.0
リリース日	2025年9月9日

この絵文字は単独の新規コードポイントとして追加された^[2]。既存の絵文字を組み合わせて表現するのではなく、U+1FACD という固有のコードが割り当てられている。

2016年〜2017年 — 世界各地から湧き上がった声

シャチ絵文字の物語は、正式な提案よりもずっと前に、しかも別々の場所で始まっている。

2016年8月、アイスランドの Jökull Ingi Þorvaldsson がChange.orgで「Make a Killer Whale Emoji」というオンライン署名活動を開始した^[4]。Appleに対してシャチの絵文字を作るよう求めるこの署名には39名が賛同した。

翌2017年2月、ドイツのUnicodeコントリビューターである Christoph Päper が、GitHubのUnicode提案トラッカー（Crissov/unicode-proposals）に「Orca emoji」のissueを立てた^[3]。クジラ（🐋）やイルカ（🐬）の絵文字は存在するのに、シャチがないのはおかしい — そんな問題提起だった。このissueには前述のChange.org署名へのリンクも添えられていた。

声は上がった。しかし声だけでは絵文字は生まれない。Unicode Consortiumに正式な提案書を提出する必要がある。

2019年2月 — 3人目が動く

2019年、この想いを1本の提案書に変えた人物がいる。スペインの開発者、Marcos Del Sol Vives だ^[5]。

2月20日、MarcosはUnicode Consortiumの絵文字小委員会（Emoji Subcommittee、以下ESC）にシャチ絵文字の提案を送った。アイスランドのJökull、ドイツのChristophとは面識のない、独立した3人目の人物だった。

さらに2020年9月、ドイツの Lukas Ewert が、これらの動きとは別にChange.org署名「Make Orcas an Emoji」を立ち上げ、356名の賛同を集めている^[15]。

世界各地の、互いに知らない人々が独立して同じことを求めていた。シャチの絵文字がほしい、と。

Marcosの提案書には、Unicode Consortiumが求めるフォーマットに従った説得力のある内容が含まれていた^[6]。

検索人気度の比較

Bingでの検索トレンドを使い、「orca」の検索人気度が「elephant（象）」とほぼ同等であることを示した。象にはすでに絵文字（🐘）があるのに、シャチにはない — この不均衡を数字で可視化した。

既存の絵文字では代替できない

Unicode の提案審査には「除外要因」という項目があり、提案者はなぜ除外すべきでないかを自ら論証する必要がある。Marcosの提案書はこれに対して明快だった^[6]。

「既存の絵文字で代用できるのでは？」— できない。シャチは「キラーホエール」と呼ばれるが科学的にはイルカの仲間であり、クジラとは外見がかなり異なる。「特殊すぎるのでは？」— フグ、コオロギ、白鳥といった動物がすでに絵文字になっている以上、シャチが特殊すぎるとは言えない。「一時的な流行では？」— シャチは約1,100万年前から地球にいる、と提案書は答えている。

サンプル画像の添付

Unicode Consortiumの規定に従い、18x18ピクセルと72x72ピクセルのサンプル画像を白黒・カラーの両方で用意した。

2019年〜2023年 — 閉ざされた門

しかし、ここからMarcosの提案は長い待ち時間に入る。

提案は2019年に送られた。しかし、正式な提案書番号 L2/24-249 がUnicode文書レジストリに登録されたのは 2024年 のことだった^[6]。2019年のDocument Registerにシャチ関連の文書は一件も存在しない^[7]。

この5年間、何が起きていたのか。調べていくと、単なる「放置」ではない、Unicode側の意図的な判断が見えてきた。

一度付けたら消せない — Unicodeの鉄の掟

まず前提として、Unicodeには 不変性（Stability Policy） という絶対的なルールがある^[17]。

Once a character is encoded, it will not be moved or removed.
（一度エンコードされた文字は、移動も削除もされない）

つまり、一度コードポイントを割り当てたら、それは人類がこの標準を使い続ける限り永久に残る。間違いがあっても取り消せない。この鉄の掟が、絵文字の追加に対する慎重さの根本にある。

戦略的休止 — 「量より質」への転換

2020年、COVID-19の影響でUnicode 14.0のリリースが6ヶ月延期された^[2]。そして2022年秋、UTC（Unicode Technical Committee）はUnicode 15.1を限定的なリリースにすると発表した。

ESCの議長 Jennifer Daniel は、この状況を「機会」と捉えた。彼女が2023年1月に発表したブログ記事「Breaking the Cycle（循環を断ち切る）」^[18]には、こう書かれている。

emoji categories are about to hit or have hit a level of saturation.
（絵文字のカテゴリは飽和に達しつつある、あるいは既に達している）

the ESC approves fewer and fewer emoji proposals every year.
（ESCは年々、承認する絵文字提案を減らしている）

ESCはこの休止期間を使い、スキントーン（肌の色）のバリエーション統一、家族絵文字の再設計、書字方向の対応といった積年の課題に取り組んだ。そして Unicode 17.0の提案受付を2024年4月まで一時的に遅らせる と決めた^[18]。

これは怠慢による停止ではなく、絵文字の追加プロセスそのものを再定義するための 意図的な休止 だった。

門の前で待つMarcosの提案

シャチ絵文字が「却下」された記録は見つからない。Charlotte Buffが管理する却下済み絵文字提案リストにも掲載されていない^[10]。Unicode公式の非承認通知アーカイブにも見当たらない^[11]。

Marcosの提案は否定されたのではない。門が閉まっていたのだ。

2024年 — 門が開く

2024年4月2日、新しいガイドラインとともに提案受付が再開された^[8]。ESCの議長Jennifer Danielもこの再開を告知している^[9]。

門が開いたとき、2019年からずっと待っていたMarcosの提案はようやく正式な文書番号 L2/24-249 を得た^[6]。同年11月、ESCが164個の新絵文字候補をUTC に提案し、シャチもその中に含まれていた^[12]。164個の内訳は、新規コードポイント9個と既存絵文字のスキントーンバリエーション約155個。最終的に新規コードポイントのうち「りんごの芯（Apple Core）」1個が取り下げられ、残りの163個がEmoji 17.0として承認された。

なお、Emoji 17.0の候補に対するPublic Review Issue（PRI #515）では、反対意見は寄せられなかった^[16]。

2025年9月9日 — 正式採用

Unicode 17.0 / Emoji 17.0の一部として、シャチ絵文字は正式に承認された^[2]。最初のオンライン署名から約9年、Marcosの提案からでも約6年半。

提案者のMarcos自身は、この経緯の詳細を公には多く語っていない。自身のサイト orca.pet には、提案の事実と採用の事実が簡潔に記録されているのみだ^[5]。

Unicodeの承認プロセス — オープン、しかし慎重

Unicodeの絵文字承認プロセスは、透明性が高い設計になっている^[13]。

提案の提出: 誰でも絵文字の提案書を提出できる
ESCでの審査: 絵文字小委員会が提案を評価し、UTCに推薦するかを判断する
UTCでの審議: 技術委員会で議論される。議事録も公開されている
ドラフト候補リストの公開: 正式承認前に候補リストが公開され、Public Review Issue（PRI）として一般からのフィードバックを受け付ける。寄せられたフィードバックは公開される^[16]
正式リリース: Unicode標準の新バージョンとしてリリースされる

提案書はすべてunicode.orgでPDFとして公開されており、誰でも読むことができる^[6]。

一度割り当てたコードポイントは永久に消せないという不変性の掟がある以上、この慎重さには理由がある。シャチの事例が示すように、提案から採用まで数年かかることは珍しくない。しかしそれは、怠慢ではなく、世界中で永久に使われる標準を定めることの重さの表れでもある。

各プラットフォームの対応状況（2026年3月時点）

プラットフォーム	対応状況
Google Noto Color Emoji	対応済み（v2.051、2025年9月12日リリース）^[14]
Apple（iOS / macOS）	iOS 26.4 / macOS 26.4 ベータで対応中。正式版は2026年3〜4月予定^[1]
X（旧Twitter）	対応済み（Twemoji v17.0）
Microsoft（Windows）	未対応。2026年3月時点でEmoji 16.0に対応したばかり

Unicodeがコードポイントと意味を定めるが、実際の見た目は各プラットフォーム（Apple、Google、Samsung等）がそれぞれ独自にデザインする。同じ U+1FACD でも、iPhoneとAndroidでは見た目が異なるのはそのためだ。

Noto Color Emoji で表示テスト

この記事では、Google の Noto Color Emoji フォントを読み込んで、新しいシャチ絵文字の表示をテストしている。

🫍

お使いのブラウザやOSがUnicode 17.0の絵文字に対応していない場合でも、Noto Color Emojiフォントを通じて表示されるはずだ。上に大きなシャチが見えていれば成功である。

まとめ

シャチ絵文字（🫍）は、アイスランド、ドイツ、スペインと世界各地の独立した声から始まり、9年かけてUnicode標準に採用された
提案者の Marcos Del Sol Vives さんは、検索データや比較論証を駆使した提案書を作成した
5年間の空白は「放置」ではなく、Unicodeが絵文字の飽和に向き合い、追加プロセスを再定義するための戦略的休止だった
Unicodeの絵文字承認プロセスは透明性が高いが、不変性という鉄の掟ゆえに慎重さが求められる

普段何気なく使っている絵文字の一つひとつに、こうした物語がある。そしてその物語は、華々しい成功譚ではなく、忍耐と偶然の積み重ねであることが多いのかもしれない。

参考文献

iPhone Mania, "iOS26.4で利用可能になる新絵文字のデザインが明らかに！" 2026年3月10日. https://iphone-mania.jp/ios-600850/
The Unicode Blog, "Unicode 17.0 Release Announcement," 2025年9月9日. http://blog.unicode.org/2025/09/unicode-170-release-announcement.html
Crissov/unicode-proposals, "Issue #103: Orca emoji," GitHub, 2017年2月5日. https://github.com/Crissov/unicode-proposals/issues/103
Jökull Ingi Þorvaldsson, "Make a Killer Whale Emoji," Change.org, 2016年8月. https://www.change.org/p/apple-make-a-killer-whale-emoji-in-apple-s-emoji-board
Marcos Del Sol Vives, "Orca emoji," orca.pet. https://orca.pet/emoji/
Marcos Del Sol Vives, "Proposal for Orca Emoji," Unicode Document L2/24-249, 2024年. https://www.unicode.org/L2/L2024/24249-orca-emoji.pdf
The Unicode Consortium, "UTC Document Register — 2019." https://www.unicode.org/L2/L2019/Register-2019.html
The Unicode Blog, "Emoji Submissions Intake Process Re-opening," 2024年3月. http://blog.unicode.org/2024/03/emoji-submissions-intake-process-re.html
Jennifer Daniel, "Emoji submissions re-opening," Substack. https://jenniferdaniel.substack.com/p/emoji-submissions-re-opening-april
Charlotte Buff, "Rejected Emoji Proposals." https://charlottebuff.com/unicode/misc/rejected-emoji-proposals/
The Unicode Consortium, "Archive of Notices of Non-Approval." https://www.unicode.org/alloc/nonapprovals.html
Emojipedia Blog, "What's New In Unicode 17.0." https://blog.emojipedia.org/whats-new-in-unicode-17-0/
The Unicode Consortium, "Submitting Emoji Proposals." https://unicode.org/emoji/proposals.html
Emojipedia Blog, "Google Debuts Emoji 17.0 Support." https://blog.emojipedia.org/google-debuts-emoji-17-0-support/
Lukas Ewert, "Make Orcas an Emoji," Change.org, 2020年9月. https://www.change.org/p/apple-make-orcas-an-emoji
The Unicode Consortium, "PRI #515: Unicode Emoji 17.0 Alpha Repertoire." https://www.unicode.org/review/pri515/
The Unicode Consortium, "Unicode Character Encoding Stability Policies." https://www.unicode.org/policies/stability_policy.html
Jennifer Daniel, "Breaking the Cycle," The Unicode Blog, 2024年3月8日（初出: 2023年1月17日）. http://blog.unicode.org/2024/03/breaking-cycle.html

DEV Community

Stop Flickering UIs: Handle Subdomains with Next.js Edge Middleware ⚡

The Challenge of Dynamic Subdomains

The Power of the Edge

Step 1: Architecting the App Router Directory

Step 2: The Middleware Logic

The Engineering ROI

Conclusion

Fonctionnement d’une blockchain - Étape 5/8 : Lien “maillon - maillon”

Qu’est-ce qu’un hash ?

Comment un hash est créé ?

Building MCP Servers in Python: a production primer for 2026

What MCP actually is

Starter: a FastMCP server in 40 lines

The transport shift: stdio → Streamable HTTP

Auth: OAuth 2.1 the boring way

Deploying to AWS without overspending

Pattern A — Low-traffic internal tools: Lambda + API Gateway

Pattern B — High-traffic shared servers: ECS Fargate behind ALB

What to expose — and what not to

What's next

I Built a Local AI VRAM Calculator & GPU Planner (Beta)

What the Planner Does

How Much VRAM Do You Need for Local LLMs?

Why This Is Single GPU Only

Where This Fits

Try It

Shadow Deployments for AI Agents: Test in Prod without breaking anything 🚀

Why Traditional Deployment Fails for Agents 🤔

The Idea Behind Shadow Deployments 🧠

What Actually Happens Under the Hood? ⚙️

Comparing Outputs Is Where the Magic Happens ⚖️

Turning Observations Into Decisions 🔁

Things That Still Need Careful Thought ⚠️

The Bigger Picture 🧩

Why Technical Startups Fail: Building in a Vacuum

The Engineer's Dilemma: Why You're Talking to Yourself

The Perfectionism Trap: When Good Enough Becomes the Enemy

The Strategy Gap: Why "Just Posting" Doesn't Work

The Blueprint for Conversion: Moving from Code to Conversation

Your Next Move: Stop Building, Start Talking

External Resources for Further Reading

gpt-image-2 API Developer Guide: Pricing, Thinking Mode, and Production Integration (2026)

gpt-image-2 API Developer Guide: Pricing, Thinking Mode, and Production Integration (2026)

Table of Contents

What Developers Need to Know in One Page {#tldr}

Pricing Breakdown: Per-Token, Per-Image, Per-Workflow {#pricing}

Why per-token instead of per-image?

Per-image cost cheat sheet

Workflow cost examples

Instant vs Thinking Mode: When to Use Which {#modes}

Decision tree

Pre-Release API Access (fal.ai, apiyi) {#pre-release}

fal.ai

apiyi.com

Code: Single Image Generation {#code-single}

Saving the image

Inline base64 (avoid the URL fetch step)

Code: 8-Image Consistent Series {#code-multi}

Use cases unlocked

Code: Image Editing / Inpainting {#code-edit}

Cost Calculator Template {#cost-calc}

Migrating from gpt-image-1 / DALL-E 3 {#migration}

From gpt-image-1

From DALL-E 3

Things to retest after migration

Rate Limits, Errors, and Production Gotchas {#production}

Common errors

Production gotchas

FAQ {#faq}

Sources

The Primeagen's '99': A New Approach to AI in Code Editors

Stelixx #StelixxInsights #IdeaToImpact #AI #BuilderCommunity #CodeEditorAI #DevCommunity #OpenSource

Best resources to learn game development with Node.js

Why Node.js is suited for certain types of games

Frontend game engines vs. backend game logic

Frontend (Client-side)

Backend (Server-side with Node.js)

Why foundational Node knowledge matters first

Educative – Learn Node.js